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DOMAIN ADMINISTRATORS OPERATIONS GUIDE 


STATUS OF THIS MEMO 


This RFC provides guidelines for domain administrators in operating a 
domain server and maintaining their portion of the hierarchical 
database. Familiarity with the domain system is assumed. 
Distribution of this memo is unlimited. 
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INTRODUCTION 


A domain server requires a few files to get started. It will 
normally have some number of boot/startup files (also known as the 
"safety belt" files). One section will contain a list of possible 
root servers that the server will use to find the up-to-date list of 
root servers. Another section will list the zone files to be loaded 
into the server for your local domain information. A zone file 
typically contains all the data for a particular domain. This guide 
describes the data formats that can be used in zone files and 
suggested parameters to use for certain fields. If you are 
attempting to do anything advanced or tricky, consult the appropriate 
domain RFC’s for more details. 


Note: Each implementation of domain software may require different 


files. Zone files are standardized but some servers may require 

other startup files. See the appropriate documentation that comes 

with your software. See the appendix for some specific examples. 
ZONES 


A zone defines the contents of a contiguous section of the domain 
space, usually bounded by administrative boundaries. There will 
typically be a separate data file for each zone. The data contained 
in a zone file is composed of entries called Resource Records (RRs). 
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You may only put data in your domain server that you are 
authoritative for. You must not add entries for domains other than 
your own (except for the special case of "glue records"). 


A domain server will probably read a file on start-up that lists the 
zones it should load into its database. The format of this file is 
not standardized and is different for most domain server 
implementations. For each zone it will normally contain the domain 
name of the zone and the file name that contains the data to load for 
the zone. 


ROOT SERVERS 


A resolver will need to find the root servers when it first starts. 
When the resolver boots, it will typically read a list of possible 
root servers from a file. 


The resolver will cycle through the list trying to contact each one. 
When it finds a root server, it will ask it for the current list of 

root servers. It will then discard the list of root servers it read 
from the data file and replace it with the current list it received. 


Root servers will not change very often. You can get the names of 
current root servers from the NIC. 


FTP the file NETINFO:ROOT-SERVERS.TXT or send a mail request to 
NIC@SRI-NIC.ARPA. 


As of this date (June 1987) they are: 


SRI-NIC.ARPA 10.0.0.51 26.0.0.73 

C.ISI.EDU 10.0.0.52 

BRL-AOS.ARPA 192.5.25.82 192.5.22.82 128.20.1.2 
A.ISI.EDU 26.3.0.103 


RESOURCE RECORDS 
Records in the zone data files are called resource records (RRs). 
They are specified in RFC-883 and RFC-973. An RR has a standard 
format as shown: 
<name> [<ttl>] [<class>] <type> <data> 
The record is divided into fields which are separated by white space. 


<name> 


The name field defines what domain name applies to the given 
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RR. In some cases the name field can be left blank and it will 
default to the name field of the previous RR. 


<ttl> 
TTL stands for Time To Live. It specifies how long a domain 
resolver should cache the RR before it throws it out and asks a 
domain server again. See the section on TTL’s. If you leave 


the TTL field blank it will default to the minimum time 
specified in the SOA record (described later). 


<class> 


The class field specifies the protocol group. If left blank it 
will default to the last class specified. 


<type> 


The type field specifies what type of data is in the RR. See 
the section on types. 


<data> 


The data field is defined differently for each type and class 
of data. Popular RR data formats are described later. 


The domain system does not guarantee to preserve the order of 
resource records. Listing RRs (such as multiple address records) in 


a certain order does not guarantee they will be used in that order. 


Case is preserved in names and data fields when loaded into the name 


server. All comparisons and lookups in the name server are case 
insensitive. 

Parenthesis ("(",")") are used to group data that crosses a line 
boundary. 

A semicolon (";") starts a comment; the remainder of the line is 
ignored. 

The asterisk ("*") is used for wildcarding. 

The at-sign ("@") denotes the current default domain name. 
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NAMES 
A domain name is a sequence of labels separated by dots. 


Domain names in the zone files can be one of two types, either 
absolute or relative. An absolute name is the fully qualified domain 
name and is terminated with a period. A relative name does not 
terminate with a period, and the current default domain is appended 
to it. The default domain is usually the name of the domain that was 
specified in the boot file that loads each zone. 


The domain system allows a label to contain any 8-bit character. 
Although the domain system has no restrictions, other protocols such 
as SMTP do have name restrictions. Because of other protocol 
restrictions, only the following characters are recommended for use 
in a host name (besides the dot separator): 


"A-Z", “a-z", "0-9", dash and underscore 


TTL’s (Time To Live) 
It is important that TTLs are set to appropriate values. The TTL is 
the time (in seconds) that a resolver will use the data it got from 
your server before it asks your server again. If you set the value 
too low, your server will get loaded down with lots of repeat 
requests. If you set it too high, then information you change will 
not get distributed in a reasonable amount of time. If you leave the 


TTL field blank, it will default to what is specified in the SOA 
record for the zone. 


Most host information does not change much over long time periods. A 
good way to set up your TTLs would be to set them at a high value, 
and then lower the value if you know a change will be coming soon. 
You might set most TTLs to anywhere between a day (86400) and a week 
(604800). Then, if you know some data will be changing in the near 
future, set the TTL for that RR down to a lower value (an hour to a 
day) until the change takes place, and then put it back up to its 
previous value. 


Also, all RRs with the same name, class, and type should have the 
same TTL value. 


CLASSES 


The domain system was designed to be protocol independent. The class 
field is used to identify the protocol group that each RR is in. 


The class of interest to people using TCP/IP software is the class 
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"Internet". Its standard designation is "IN". 


A zone file should only contain RRs of the same class. 


TYPES 
There are many defined RR types. For a complete list, see the domain 
specification RFCs. Here is a list of current commonly used types. 


The data for each type is described in the data section. 


Designation Description 
SOA Start Of Authority 
NS Name Server 
A Internet Address 
CNAME Canonical Name (nickname pointer) 
HINFO Host Information 
WKS Well Known Services 
MX Mail Exchanger 
PTR Pointer 


SOA (Start Of Authority) 


<name> [<ttl>] [<class>] SOA <origin> <person> ( 
<serial> 
<refresh> 
<retry> 
<expire> 
<minimum> ) 


The Start Of Authority record designates the start of a zone. The 
zone ends at the next SOA record. 


<name> is the name of the zone. 


<origin> is the name of the host on which the master zone file 
resides. 


<person> is a mailbox for the person responsible for the zone. It is 
formatted like a mailing address but the at-sign that normally 


separates the user from the host name is replaced with a dot. 


<serial> is the version number of the zone file. It should be 
incremented anytime a change is made to data in the zone. 
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NS 


<refresh> is how long, in seconds, a secondary name server is to 
check with the primary name server to see if an update is needed. A 
good value here would be one hour (3600). 


<retry> is how long, in seconds, a secondary name server is to retry 
after a failure to check for a refresh. A good value here would be 
10 minutes (600). 


<expire> is the upper limit, in seconds, that a secondary name server 
is to use the data before it expires for lack of getting a refresh. 
You want this to be rather large, and a nice value is 3600000, about 
42 days. 


<minimum> is the minimum number of seconds to be used for TTL values 
in RRs. A minimum of at least a day is a good value here (86400). 


There should only be one SOA record per zone. A sample SOA record 
would look something like: 


@ IN SOA SRI-NIC.ARPA. HOSTMASTER.SRI-NIC.ARPA. ( 
45 ;serial 
3600 ;rvefresh 
600 ;retry 
3600000 ;expire 
86400 ) ;minimum 


(Name Server) 
<domain> [<ttl>] [<class>] NS <server> 


The NS record lists the name of a machine that provides domain 
service for a particular domain. The name associated with the RR is 
the domain name and the data portion is the name of a host that 
provides the service. If machines SRI-NIC.ARPA and C.ISI.EDU provide 
name lookup service for the domain COM then the following entries 
would be used: 


COM. NS SRI-NIC.ARPA. 
NS C.ISI.EDU. 


Note that the machines providing name service do not have to live in 
the named domain. There should be one NS record for each server for 
a domain. Also note that the name "COM" defaults for the second NS 
record. 


NS records for a domain exist in both the zone that delegates the 
domain, and in the domain itself. 
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GLUE RECORDS 
If the name server host for a particular domain is itself inside the 
domain, then a ’glue’ record will be needed. A glue record is an A 
(address) RR that specifies the address of the server. Glue records 
are only needed in the server delegating the domain, not in the 
domain itself. If for example the name server for domain SRI.COM was 


KL.SRI.COM, then the NS record would look like this, but you will 
also need to have the following A record. 


SRI.COM. NS 
KL.SRI.COM. KL.SRI.COM. A 10.1.0.2. 
A (Address) 
<host> [<ttl>] [<class>] A <address> 


The data for an A record is an internet address in dotted decimal 
form. A sample A record might look like: 


SRI-NIC.ARPA,. A 10.0.0.51 
There should be one A record for each address of a host. 


CNAME ( Canonical Name) 


<nickname> [<ttl>] [<class>] CNAME <host> 
The CNAME record is used for nicknames. The name associated with the 
RR is the nickname. The data portion is the official name. For 


example, a machine named SRI-NIC.ARPA may want to have the nickname 
NIC.ARPA. In that case, the following RR would be used: 


NIC.ARPA. CNAME SRI-NIC.ARPA. 


There must not be any other RRs associated with a nickname of the 
same class. 


Nicknames are also useful when a host changes it’s name. In that 


case, it is usually a good idea to have a CNAME pointer so that 
people still using the old name will get to the right place. 
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HINFO (Host Info) 


WKS 


MX 


<host> [<ttl>] [<class>] HINFO <hardware> <software> 


The HINFO record gives information about a particular host. The data 
is two strings separated by whitespace. The first string is a 
hardware description and the second is software. The hardware is 
usually a manufacturer name followed by a dash and model designation. 
The software string is usually the name of the operating system. 


Official HINFO types can be found in the latest Assigned Numbers RFC, 
the latest of which is RFC-1010. The Hardware type is called the 
Machine name and the Software type is called the System name. 


Some sample HINFO records: 


SRI-NIC.ARPA. HINFO DEC-2060 TOPS20 
UCBARPA.Berkeley.EDU. HINFO VAX-11/780 UNIX 


(Well Known Services) 
<host> [<ttl>] [<class>] WKS <address> <protocol> <services> 


The WKS record is used to list Well Known Services a host provides. 
WKS’s are defined to be services on port numbers below 256. The WKS 
record lists what services are available at a certain address using a 
certain protocol. The common protocols are TCP or UDP. A sample WKS 
record for a host offering the same services on all address would 
look like: 


Official protocol names can be found in the latest Assigned Numbers 
RFC, the latest of which is RFC-1010. 


SRI-NIC.ARPA. WKS 10.0.0.51 TCP TELNET FTP SMTP 
WKS 10.0.0.51 UDP TIME 
WKS 26.0.0.73 TCP TELNET FTP SMTP 
WKS 26.0.0.73 UDP TIME 


(Mail Exchanger) (See RFC-974 for more details.) 
<name> [<ttl>] [<class>] MX <preference> <host> 


MX records specify where mail for a domain name should be delivered. 
There may be multiple MX records for a particular name. The 
preference value specifies the order a mailer should try multiple MX 
records when delivering mail. Zero is the highest preference. 
Multiple records for the same name may have the same preference. 
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A host BAR.FOO.COM may want its mail to be delivered to the host 
PO.FOO.COM and would then use the MX record: 

BAR.FOO.COM. MX 10 PO.FOO.COM. 


A host BAZ.FOO.COM may want its mail to be delivered to one of three 
different machines, in the following order: 


BAZ .FOO.COM. MX 10 PO1.FOO.COM. 
MX 20 PO2.FOO.COM. 
MX 30 PO3.FOO.COM. 


An entire domain of hosts not connected to the Internet may want 
their mail to go through a mail gateway that knows how to deliver 
mail to them. If they would like mail addressed to any host in the 
domain FOO.COM to go through the mail gateway they might use: 


FOO.COM. MX 10 RELAY.CS.NET. 
* .FOO.COM. MX 20 RELAY.CS.NET. 


Note that you can specify a wildcard in the MX record to match on 
anything in FOO.COM, but that it won’t match a plain FOO.COM. 


IN-ADDR.ARPA 


The structure of names in the domain system is set up ina 
hierarchical way such that the address of a name can be found by 
tracing down the domain tree contacting a server for each label of 
the name. Because of this ’indexing’ based on name, there is no easy 
way to translate a host address back into its host name. 


In order to do the reverse translation easily, a domain was created 
that uses hosts’ addresses as part of a name that then points to the 
data for that host. In this way, there is now an ’index’ to hosts’ 
RRs based on their address. This address mapping domain is called 
IN-ADDR.ARPA. Within that domain are subdomains for each network, 
based on network number. Also, for consistency and natural 
groupings, the 4 octets of a host number are reversed. 


For example, the ARPANET is net 10. That means there is a domain 
called 10.IN-ADDR.ARPA. Within this domain there is a PTR RR at 
51.0.0.10.IN-ADDR that points to the RRs for the host SRI-NIC.ARPA 
(who’s address is 10.0.0.51). Since the NIC is also on the MILNET 
(Net 26, address 26.0.0.73), there is also a PTR RR at 73.0.0.26.IN- 
ADDR.ARPA that points to the same RR’s for SRI-NIC.ARPA. The format 
of these special pointers is defined below along with the examples 
for the NIC. 
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PTR 
<special-name> [<ttl>] [<class>] PTR <name> 


The PTR record is used to let special names point to some other 
location in the domain tree. They are mainly used in the IN- 
ADDR.ARPA records for translation of addresses to names. PTR’s 
should use official names and not aliases. 


For example, host SRI-NIC.ARPA with addresses 10.0.0.51 and 26.0.0.73 
would have the following records in the respective zone files for net 
10 and net 26: 


51.0.0.10.IN-ADDR.ARPA. PTR SRI-NIC.ARPA. 
73.0.0.26.IN-ADDR.ARPA. PTR SRI-NIC.ARPA. 


GATEWAY PTR’s 
The IN-ADDR tree is also used to locate gateways on a particular 


network. Gateways have the same kind of PTR RRs as hosts (as above) 
but in addition they have other PTRs used to locate them by network 


number alone. These records have only 1, 2, or 3 octets as part of 
the name depending on whether they are class A, B, or C networks, 
respectively. 


Lets take the SRI-CSL gateway for example. It connects 3 different 
networks, one class A, one class B and one class C. It will have the 
standard RR’s for a host in the CSL.SRI.COM zone: 

GW.CSL.SRI.COM. A 10.2.0.2 
A 128.18.1.1 
A 192 312233" 2 


Also, in 3 different zones (one for each network), it will have one 
of the following number to name translation pointers: 


2.0.2.10.IN-ADDR.ARPA. PTR GW.CSL.SRI.COM. 
1.1.18.128.IN-ADDR.ARPA. PTR GW.CSL.SRI.COM. 
1.33.12.192.IN-ADDR.ARPA. PTR GW.CSL.SRI.COM. 


In addition, in each of the same 3 zones will be one of the following 
gateway location pointers: 


10.IN-ADDR.ARPA. PTR GW.CSL.SRI.COM. 
18.128.IN-ADDR.ARPA. PTR GW.CSL.SRI.COM. 
33.12.192.IN-ADDR.ARPA. PTR GW.CSL.SRI.COM. 
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INSTRUCTIONS 
Adding a subdomain. 
To add a new subdomain to your domain: 
Setup the other domain server and/or the new zone file. 


Add an NS record for each server of the new domain to the zone 
file of the parent domain. 


Add any necessary glue RRs. 
Adding a host. 
To add a new host to your zone files: 
Edit the appropriate zone file for the domain the host is in. 
Add an entry for each address of the host. 
Optionally add CNAME, HINFO, WKS, and MX records. 


Add the reverse IN-ADDR entry for each host address in the 
appropriate zone files for each network the host in on. 


Deleting a host. 
To delete a host from the zone files: 


Remove all the hosts’ resource records from the zone file of 
the domain the host is in. 


Remove all the hosts’ PTR records from the IN-ADDR zone files 
for each network the host was on. 


Adding gateways. 
Follow instructions for adding a host. 


Add the gateway location PTR records for each network the 
gateway is on. 


Deleting gateways. 
Follow instructions for deleting a host. 


Also delete the gateway location PTR records for each network 


Lottor [Page 11] 


RFC 1033 DOMAIN OPERATIONS GUIDE November 1987 


the gateway was on. 


COMPLAINTS 


These are the suggested steps you should take if you are having 
problems that you believe are caused by someone else’s name server: 


1. Complain privately to the responsible person for the domain. You 
can find their mailing address in the SOA record for the domain. 

2. Complain publicly to the responsible person for the domain. 

3. Ask the NIC for the administrative person responsible for the 
domain. Complain. You can also find domain contacts on the NIC in 
the file NETINFO:DOMAIN-CONTACTS.TXT 


4. Complain to the parent domain authorities. 


5. Ask the parent authorities to excommunicate the domain. 
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EXAMPLE DOMAIN SERVER DATABASE FILES 


The following examples show how zone files are 
SRI will be used as the example 
decided to divided their domain SRI.COM into a 
The subdomains 


organization. 
for each group that wants one. 


Note the following interesting items: 


DOMAIN OPERATIONS GUIDE 


November 1987 


set up for a typical 
organization. SRI has 
few subdomains, one 
are CSL and ISTC. 


There are both hosts and domains under SRI.COM. 


CSL.SRI.COM is both a domain name and a host name. 


All the domains are serviced by the same pair of domain servers. 


All hosts at SRI are on net 128.18 except hosts in the CSL domain 


which are on net 192.12.33. 


correspond to a physical network. 


Note that a domain does not have to 


The examples do not necessarily correspond to actual data in use 
by the SRI domain. 
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SRI Domain Organization 


4+------- + 
| com | 
4+------- + 
| 
4+------- + 
| SRI | 
+------—- + 
| 
4+---------- ++----------- 
| | 
4+------- + 4+------ + 4+------- + 
| csL | aste || | Hosts | 
4+------- + 4+------ + 4+------- + 
| | 
4+------- + 4+------- + 
| Hosts | | Hosts | 
4+------- + 4+------- + 
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[File "CONFIG.CMD". Since bootstrap files are not standardized, this 
file is presented using a pseudo configuration file syntax.] 


load root server list from file ROOT.SERVERS 
load zone SRI.COM. from file SRI.ZONE 
load zone CSL.SRI.COM. from file CSL.ZONE 
load zone ISTC.SRI.COM. from file ISTC.ZONE 
load zone 18.128.IN-ADDR.ARPA. from file SRINET. ZONE 


load zone 33.12.192.IN-ADDR.ARPA. from file SRI-CSL-NET. ZONE 
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[File "ROOT.SERVERS". Again, the format of this file is not 


standardized. ] 


;list of possible root servers 
SRI-NIC.ARPA 10.0.0.51 26:210...0:273' 


C.ISI.EDU 10.0.0.52 
BRL-AOS.ARPA 192.5.25.82 192.5.22.82 128.20.1.2 


A.ISI.EDU 26.3.0.103 
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[File "SRI.ZONE"] 


SRI.COM. IN SOA KL.SRI.COM. DLE.STRIPE.SRI.COM. ( 
870407 ;serial 
1800 ;refresh every 30 minutes 
600 ;retry every 10 minutes 


604800 ;expire after a week 
86400 ;default of an hour 
) 


SRI.COM. NS KL.SRI.COM. 
NS STRIPE.SRI.COM. 
MX 10 KL.SRI.COM. 


;SRI.COM hosts 


KL A 10.1402 
A 128.18.10.6 
MX 10 KL.SRI.COM. 
STRIPE A 10.4.0.2 
STRIPE A 128.18.10.4 
MX 10 STRIPE.SRI.COM. 
NIC CNAME SRI-NIC.ARPA. 
Blackjack A T2831 8% 22ed. 
HINFO VAX-11/780 UNIX 
WKS 128.18.2.1 TCP TELNET FTP 
CSL A 192.12.33.2 
HINFO FOONLY-F4 TOPS20 
WKS 192 2123322 TCP TELNET FTP SMTP FINGER 
MX 10 CSL.SRI.COM. 
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[File "CSL.ZONE"] 


CSL.SRI.COM. IN SOA KL.SRI.COM. DLE.STRIPE.SRI.COM. ( 
870330 ;serial 
1800 ;refresh every 30 minutes 
600 ;retry every 10 minutes 


604800 ;expire after a week 
86400 ;default of a day 
) 


CSL.SRI.COM. NS KL.SRI.COM. 
NS STRIPE.SRI.COM. 
A 19212553362 


;CSL.SRI.COM hosts 


A CNAME CSL.SRI.COM. 
B A 19262 33.53 

HINFO FOONLY-F4 TOPS20 

WKS 192212 233.23 TCP TELNET FTP SMTP 
GW A 10.2.0.2 

A 192202103 3-01 

A 128.18.1.1 

HINFO PDP-11/23 MOS 
SMELLY A 1927123334 

HINFO IMAGEN IMAGEN 
SQUIRREL A TIZIO 

HINFO XEROX-1100 INTERLISP 
VENUS A 192.121. 33T 


INFO SYMBOLICS-3600 LISPM 


HELIUM A 192.12.33.30 

HINFO SUN-3/160 UNIX 
ARGON A 19212333L 

HINFO SUN-3/75 UNIX 
RADON A 192.123332 

HINFO SUN-3/75 UNIX 
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[File "ISTC.ZONE"] 


ISTC.SRI.COM. 


ISTC.SRI.COM. 


; ISTC hosts 
joyce 

bozo 

sundae 


tsca 


tsc 


prmh 


spam 
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IN SOA 


NS 
NS 


wpa 


INFO 


ci 


INFO 


Dp pP p 


KL.SRI.COM. roemers.JOYCE.ISTC.SRI.COM. ( 


870406 ;serial 
1800 ;refresh every 30 minutes 
600 ;retry every 10 minutes 
604800 ;expire after a week 
86400 ;default of a day 
) 
KL.SRI.COM. 
STRIPE.SRI.COM. 
10 SPAM.ISTC.SRI.COM. 
128.18.4.2 
VAX-11/750 UNIX 
128.18.0.6 
SUN UNIX 
128.18.0.11 
SUN UNIX 
128.18.0.201 
1.0.°3:2.0:52 


VAX-11/750 UNIX 

10 TSCA.ISTC.SRI.COM. 
tsca 

128.18.0.203 

10.2.0.51 

PDP-11/44 UNIX 
128.18.4.3 

102 4.0107 

VAX-11/780 UNIX 

10 SPAM.ISTC.SRI.COM. 
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[File "SRINET.ZONE"] 


18.128.IN-ADDR.ARPA. IN SOA KL.SRI.COM DLE.STRIPE.SRI.COM. ( 
870406 ;serial 
1800 ;refresh every 30 minutes 
600 ;retry every 10 minutes 


604800 ;expire after a week 
86400 ;default of a day 
) 


18.128.IN-ADDR.ARPA. NS KL.SRI.COM. 
NS STRIPE.SRI.COM. 
PTR GW.CSL.SRI.COM. 


; SRINET [128.18.0.0] Address Translations 


; SRI.COM Hosts 
1.2.18.128.IN-ADDR.ARPA. PTR Blackjack.SRI.COM. 


; ISTC.SRI.COM Hosts 


2.4.18.128.IN-ADDR.ARPA. PTR joyce. ISTC.SRI.COM. 
6.0.18.128.IN-ADDR.ARPA. PTR bozo.ISTC.SRI.COM. 
11.0.18.128.IN-ADDR.ARPA. PTR sundae.ISTC.SRI.COM. 
201.0.18.128.IN-ADDR.ARPA. PTR tsca.ISTC.SRI.COM. 
203.0.18.128.IN-ADDR.ARPA. PTR prmh.ISTC.SRI.COM. 
3.4.18.128.IN-ADDR.ARPA. PTR spam. ISTC.SRI.COM. 


; CSL.SRI.COM Hosts 
1.1.18.128.IN-ADDR.ARPA. PTR GW.CSL.SRI.COM. 
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[File 


33012 


33.12 


; SRI-CSL-NET 
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"SRI-CSL-NET. ZONE" ] 


-192.IN-ADDR.ARPA. IN 


.192.IN-ADDR.ARPA. NS 


NS 
PTR 


; SRI.COM Hosts 


2.33.12.192.IN-ADDR.ARPA. 
7 CSL.SRI.COM Hosts 

1.33.12.192.IN-ADDR.ARPA. 
3.33.12.192.IN-ADDR.ARPA. 
4.33.12.192.IN-ADDR.ARPA. 
5.33.12.192.IN-ADDR.ARPA. 
7.33.12.192.IN-ADDR.ARPA. 


30.33.12.192.IN-ADDR.ARPA. 
31.33.12.192.IN-ADDR.ARPA. 
32.33.12.192.IN-ADDR.ARPA. 
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SOA KL.SRI.COM DLE.STRIPE.SRI.COM. ( 


870404 ;serial 
1800 ;refresh every 30 minutes 
600 ;retry every 10 minutes 
604800 ;expire after a week 
86400 ;default of a day 
) 

KL.SRI.COM. 


STRIPE.SRI.COM. 
GW.CSL.SRI.COM. 


PTR 


PTR 
PTR 
PTR 
PTR 
PTR 
PTR 
PTR 
PTR 


[192.12.33.0] Address Translations 


CSL.SRI.COM. 


GW.CSL.SRI.COM. 
B.CSL.SRI.COM. 
SMELLY.CSL.SRI.COM. 
SQUIRREL.CSL.SRI.COM. 
VENUS .CSL.SRI.COM. 
HELIUM.CSL.SRI.COM. 
ARGON.CSL.SRI.COM. 
RADON.CSL.SRI.COM. 
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APPENDIX 


BIND 
UNIX 


This 
boot 


DOMAIN OPERATIONS GUIDE 


(Berkeley Internet Name Domain server) 


section describes two BIND implementation specific files; 
file and the cache file. 


BIND has othe 


specifications that are not described here. 
Operations Guide for BIND for details. 


The boot file for BIND is usually called "named.boot". 
corresponds to file "CONFIG.CMD" 


The cache file for BIND is usually called "named.ca". 
corresponds to file "ROOT.SERVERS" 
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distributed with 4.3 BSD 


the 
r options, files, and 
See the Name Server 


This 
ple section. 


cache 

primary 
primary 
primary 
primary 
primary 


SRI.COM 

CSL.SRI.COM 
ISTC.SRI.COM 
18.128.IN-ADDR.ARPA 
33.12.192.IN-ADDR.ARPA 


named.ca 

SRI .ZONE 

CSL. ZONE 

ISTC. ZONE 
SRINET. ZONE 
SRI-CSL-NET. ZONE 


in the ex 


This 
ample section. 


;list of possible root servers 


1 


jand their addresses 


SRI-NIC.ARPA. 


C.ISI.EDU. 
BRL-AOS.ARPA. 


A.ISI.EDU. 


IN NS SRI-NIC 
NS C.ISI.E 
NS BRL-AOS 
NS C.ISI.E 
A 10.0.0. 
A 26.0.0. 
A 10.0.0. 
A 192752 
A 192.5.2 
A 128.20. 
A 26.3.0. 


- ARPA. 
DU. 
- ARPA. 
DU. 


51 
73 
52 
5.82 
2.82 
12 
103 
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